While the TCP sending rate is normally controlled by the sender, there are scenarios and environments, where the receiver has some knowledge of the used links and bit rates, which make it worthwhile to let the receiver control the data transmission rate of the sender to some extent. In order to apply this mechanism, the receiver should have knowledge of the Round Trip Time (RTT) value to control or limit the sender's bit rate. As a result, the sender would not have to probe for the available bit rate by itself, which normally comes to the expense of packet losses and is less accurate than the receiver's information.
The sending bit rate in the TCP sender is controlled by a sliding window called congestion window. The sender sends data and receives cumulative acknowledgements. Outstanding data is the data that the sender has already sent, but has not received acknowledgements for it. The sender is allowed to have the amount of outstanding data equal to the current value of the congestion window. Because the data is usually acknowledged one RTT after it was sent, the allowed sending bit rate, B_send can be calculated from the RTT and the congestion window size, cwnd, as: B_send=cwnd/RTT. An example of these typical values could be RTT=100 ms and B_send=64 Kbit/s.
The congestion window at the server is dynamically adjusted according to gathered network information, e.g. in cases of packet losses, the TCP sender would assume congestion in the network and deflate the window. In cases of no packet losses, the window is slightly and regularly increased. However, the window which TCP uses to control the sending of data packets, is the minimum of the congestion window and another window-size signalled by the receiver called the advertised window, awnd. This is usually used for the flow control features of TCP, i.e. to ensure that a fast TCP sender does not send more data than the receiver can consume.
In conclusion, the receiver can limit the upper sending rate of the sender of a TCP connection, by using the integrated flow control and send an advertised window with the value calculated from RTT and maximum sending bit rate.
If only one connection member has data to send, RTT measurements for the receiver in a TCP connection is only possible at the beginning of a connection (TCP starts with a 3-way handshake). The measurement, which the receiver can perform at connection setup, is not accurate, because it is based on small control packets (usually around 40 bytes). The data packets are much larger in size, e.g. 1500 bytes, and thus the RTT is usually much higher than for the small control packets.
Considering this, receivers can make a rough RTT measurement at connection set-up, but do not have further RTT information afterwards. As the RTT is usually dynamic and variable in IP networks, the receiver should collect RTT information more frequently to perform a reliable sending bit rate control at the sender.
As described above, the receiver in a TCP connection can control the sending bit rate of the sender by signalling an upper limit in form of the advertised window. However, in order to calculate an advertised window to be signalled, the receiver needs an RTT measurement. The better and more accurate the measurement is, the better is the window calculation and the better is the link usage after the sender adopted the window size.